Security and Permissions
Ability to Run FormFusion Jobs
One of the features of FormFusion is that it is completely invisible to the end user. If the user can run a job in the ERP system, they can run it through FormFusion as long as the template has been set up by a template developer. To run a job through FormFusion, the user specifies the print parameter for that template, and runs it normally. The user does not need any special privileges or permissions to do this since the job itself runs as the MAPS user in the evicfg file.
Access to FormFusion Configuration
The Administer Environments area of FormFusion can only be accessed by administrators. It is grayed out for other user types.
Template Development Permissions
There are three areas where permissions are given or denied to template developers:
- Permissions in MAPS determine whether a MAPS user can access FormFusion.
- Object security within FormFusion controls access to individual environments, templates, etc.
- FormFusion 3.3 and higher locks templates that are currently being edited, so that only one developer can work on a given template at a time.
MAPS Authorizations
Developing FormFusion templates requires a login to MAPS. Similar to the evicfg MAPS user, this user must be authorized in MAPS to use the FormFusion application, the data connection(s) to the database(s), and any printers or email servers that will be used with FormFusion. Refer to the MAPS documentation for more information on this topic.
Application
A user who does not have permission to use the FormFusion application will see FormFusion in the list, but will receive an error when attempting to log in:
To give permissions, a MAPS administrator must go to the Applications tab of the MAPS Configuration Tool, select FormFusion, and add the user or group the user is a member of in the “authorized for use with” pane on the right.
Data Connection
- Template developers need permissions to use the database connection that is being used to run CaptureForm queries.
- Developers can only see data connections that they are authorized to use. When overriding the default connection set in the environment, the developer needs to be authorized for the new connection.
- In order to test a template or queries, the developer needs to be able to use the data connection when logged in as their own username. Note that when calling FormFusion from a host system, the user running the job is the user in the evicfg file. In contrast, when a developer logs in to FormFusion, any jobs they run via test print or queries run using the test button will run as the user they are logged in as.
- The data connection needs to be set up correctly, with a valid database username/password specified for each user or group that has been authorized to use the connection. If the database credentials are not valid, running the template will produce an error: ORA-00942: table or view does not exist.
- To see what database credentials are assigned to a specific MAPS user, go to the Data Connections screen in MAPS and select the connection being used with this template. Click Edit Connection. On the User/Group rules tab, find the user or group this user is a member of, and look on the right to see how they are connecting.
Printers and Email Servers
If test printing templates from FormFusion, the developer needs to be authorized in MAPS for any printers or mail servers they will be using. Otherwise, they can test running jobs through the ERP system, which runs all FormFusion jobs as the evicfg user. It is significantly easier and faster to test print from FormFusion, since the same input file can be used over and over.
FormFusion Object Security
It is also possible to set security on individual objects in FormFusion. To do so, log in as an administrator user type (or another user with appropriate permissions granted in MAPS), right-click on the object, and go to Security.
Non-administrators can view the security permissions for objects they have permissions to view, but cannot edit the permissions unless they have the “change permissions” privilege. Otherwise, specific users and groups can be denied access to read, modify, change permissions, etc. on any FormFusion object.
FormFusion objects are organized into a tree structure in which some objects are children of other objects. For example, a print parameter is the "child" of a process (which is the print parameter's parent). The permissions below relate to what a user can do to an object and/or the object's children.
Select a user or group from the list to configure permissions, or click the Add. . . button to add a new user or group to the list. You can Allow or Deny any of the following:
- Full: Perform any action, including modifying permissions for any user, including themselves. Checking this option has the same effect as checking all the other options individually.
- Change Permissions: Modify permissions for any user, including themselves. Note that this permission is the same in some respects as Full, since the user could easily enable Full if granted Change Permissions.
- Read: Allows the user to open and read child objects of the selected object without the permission to make any changes.
- Modify: Create or Modify child objects of the selected object. Typically this permission would be placed on a folder to enable children to be created. If you cannot determine why a given user or group is able to Create or Modify certain objects, examine the parent of the object in question for this permission.
- View Children: View the object and the children of the object. Typically this permission would be placed on a folder or process to enable children of that object to be viewed. If you cannot determine why a given user or group is able to see a given object, examine the parent of the object in question for this permission.
- Create/Modify Children: Create or Modify child objects of the selected object. Typically this permission would be placed on a folder, process or print parameter to enable children to be created. If you cannot determine why a given user or group is able to Create or Modify certain objects, examine the parent of the object in question for this permission.
To remove security for a user or group, select the user or group that needs to be removed and click the Remove button. Note that they may still have permissions due to membership in other groups.
Group vs. user security: User permissions are a sum of all of the group permissions the user has. However, any security defined on an individual user supersedes all group security.
Inherited permissions: Objects in FormFusion automatically inherit the permissions of their parent unless otherwise specified.
“Everyone” group: All MAPS users are automatically a member of the “Everyone” group. It is often a good policy to deny permissions to the “Everyone” group once other groups have been established.
Template Locking
FormFusion 1.9 had a feature that would prevent two users from editing the same template at the same time. This has been brought back in version 3.3. If someone is already in a template, the second person who tries to access it sees a message:
Administrator user types have the option of breaking the lock. This can be useful in situations where a user has left a template open and is not available to release the lock:
Clicking “Yes” requires the administrator to type the word “YES” to confirm, and then breaks the user’s lock.
Important note: After losing their lock, if someone else makes changes to the template then the original user will be unable to save any changes they may have made. For this reason, an administrator should only break a lock when absolutely necessary.
Template locks can also be broken if the user's connection to MAPS has been interrupted (user lost Internet access, MAP server restarted, etc.). If a user has been making changes and lost their lock, one of three situations will occur when they attempt to save:
- If no one else has opened the template since the user lost their lock, FormFusion will automatically reacquire it.
- If another user has opened the template, is still working in it, but has not saved any changes, the original user sees the message indicating that the template is currently locked by that user and cannot be edited.
- If another user has made changes to the template and saved them, any work the original user made will be lost, and they will be prompted to reopen the FormStamp to get the updated version.